概要
RAG（Retrieval-Augmented Generation）システムを構築する際、Embeddingモデルの選択は、システムの性能・コスト・運用体制を左右します。クラウドAPIを使うか、ローカルLLMで完結させるかによって、実装方法と運用負荷が変わります。
DigitalBaseでの構築知見をもとに、OpenAI API と Ollama（ローカルLLM） の選定に必要なモデルの特徴、メタデータ設計、コスト構造、本番運用での注意点を整理します。
Embeddingモデルの選択
OpenAI API
OpenAIでは執筆時点で text-embedding-3-small が標準的な選択肢です。主な特徴は以下のとおりです。
- 次元数: 1536次元（
dimensionsパラメータで256〜1536の範囲に調整可能） - コスト: $0.02 / 1M tokens
- 性能: MTEB（Massive Text Embedding Benchmark）で高いスコアを記録
- コンテキスト長: 8,191トークンまで対応
次元数を削減することで、ベクトルDBのストレージコストを抑えつつ、検索性能の大幅な低下を避けられます。たとえば512次元に削減しても、多くのユースケースで実用的な精度を維持できます。より高精度を求める場合は text-embedding-3-large（3072次元）も選択肢になりますが、コストとストレージが増える点に留意が必要です。
Ollama（ローカルLLM）
Ollamaでは以下のオープンソースモデルが利用可能です。
- nomic-embed-text: 768次元、コンテキスト長8,192トークン
- mxbai-embed-large: 1024次元、高精度だがリソース消費が大きい
- all-minilm: 384次元、軽量で高速
ローカル実行のため、API利用料が発生せず、データの外部送信が不要という利点があります。医療・金融・製造業など、機密性の高いデータを扱う場合に特に有効です。
ベクトルDBへの格納とメタデータ設計
Embedding生成の方式にかかわらず、メタデータを事前に設計することで、運用時の手戻りを減らせます。
推奨メタデータ構造
metadata = { "document_id": "doc_12345", # 必須 "chunk_index": 0, "source": "product_manual.pdf", "created_at": "2026-06-15T10:30:00Z", "page_number": 5, "section": "第3章" }
document_id を含めることで、次のような運用が容易になります。
- 差分更新: 特定ドキュメントのチャンクのみを再生成・更新できる
- 削除操作: ドキュメント単位での一括削除が容易になる
- 追跡性: 検索結果の出典追跡とトラブルシューティングが簡単になる
実装例（ChromaDB）
import chromadb client = chromadb.Client() collection = client.create_collection("documents") # ドキュメント更新時は既存チャンクを削除 collection.delete( where={"document_id": "doc_12345"} ) # 新しいチャンクを追加 collection.add( embeddings=embeddings, documents=chunks, metadatas=metadatas, ids=[f"doc_12345_chunk_{i}" for i in range(len(chunks))] )
業務システムでの本番運用では、PostgreSQL拡張の pgvector（HNSWインデックス）のように、既存のRDBインフラと統合できるベクトルストアも選択肢です。権限管理や監査ログとの連携では、既存のデータ基盤と統合できる利点があります。
コストとパフォーマンスの比較
OpenAI API
メリット
- 高精度な検索結果
- インフラ管理が不要
- スケーラビリティが高い
デメリット
- 従量課金のため利用量増に比例してコストが増える
- データを外部に送信する
- APIレート制限の考慮が必要
Ollama
メリット
- API利用料が発生しない（サーバーコストのみ）
- データの外部送信が不要
- レート制限がない
デメリット
- インフラ運用が必要
- モデルによってはOpenAIより精度が劣る可能性がある
- スループット拡大にはハードウェア投資が必要
コスト比較では、OpenAI APIの従量課金と、Ollamaを稼働させるインフラの費用を確認します。
選択基準とユースケース
OpenAI APIが適しているケース
- スタートアップ・小規模運用: 初期投資を抑えたい
- 可変ワークロード: 月ごとの利用量が大きく変動する
- 高精度が要件: カスタマーサポートなど検索精度が直接成果に影響する
- 開発リソースが限られる: インフラ管理に人員を割けない
Ollamaが適しているケース
- データ主権の重視: 医療・金融・製造業など機密データを外に出せない
- オフライン・閉域環境: インターネット接続が制限される環境
- カスタマイズ重視: モデルの選定・ファインチューニングを自社で行いたい
ハイブリッドアプローチ
実務では、両者を組み合わせる構成も有効です。
- 開発環境: OpenAI APIで迅速にプロトタイプを構築する
- 本番環境: Ollamaで運用コストを抑える
- フォールバック: ローカル基盤の障害時にOpenAI APIへ一時的に切り替える
ただし、OpenAIとOllamaではEmbeddingのベクトル空間が異なるため、両者を混在させる場合は同一インデックス内でモデルを混ぜないことが前提です。モデルを切り替える際は、原則として全チャンクの再Embeddingが必要になる点に注意してください。
まとめ
RAGのEmbedding選定では、業務要件・コスト構造・データ主権を確認します。OpenAI APIとOllamaの特徴を踏まえて構成を選び、メタデータ設計で文書の更新・削除・出典追跡を支えることが、本番運用の保守性につながります。
モデルを切り替える場合は、全チャンクの再Embeddingを原則として計画に含めます。実装・測定・改善を通じて、自社の要件に合った構成を検討します。